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Disclaimer 


These  proceedings  are  a summary  of  the  NIST-sponsored  workshop  on  Knowledge-based  Systems 
Interoperability:  Standards  and  Implementation  Issues,  which  was  held  on  3 and  4 November  1997. 
Because  participants  included  software  users  and  representatives  from  commercial  vendors,  certain 
products  are  identified  in  this  report  to  present  specific  views  and  to  facilitate  understanding  of  concepts 
and  implementations.  The  National  Institute  of  Standards  and  Technology  does  not  judge,  recommend  or 
endorse  these  products.  The  opinions  expressed  in  this  report  are  those  of  the  workshop  participants  and 
not  necessarily  those  of  NIST  or  its  employees. 

Being  published  by  the  United  States  Government,  this  report  is  not  subject  to  copyright. 
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Introduction 


On  3 and  4 November  1997,  the  National  Institute  of  Standards  and  Technology  (NIST)  sponsored1  an 
information-gathering  workshop  that  focused  on  "Knowledge-based  Systems  Interoperability."  Held  in 
Gaithersburg,  MD  on  the  NIST  campus,  and  in  response  to  the  growing  need  for  integrating  knowledge  in 
distributed  computing  environments,  the  workshop  addressed  the  general  issue  of  interoperability  among 
knowledge-based  systems2  especially  in  engineering  design  and  manufacture.  The  workshop,  which  had 
more  than  thirty  participants,  included  seven  presentations  from  developers,  vendors  and  users,  group 
discussions  on  knowledge-based  system  interoperability  --  its  present  capabilities  and  some  of  its  main 
drawbacks  — and  a general  session  to  target  specific  research  and  development,  and  end-user  needs.  This 
report  documents  the  workshop  background  and  goals,  its  participants  and  agenda,  the  speakers’  abstracts 
and  slides,  and  provides  a summary  of  the  workshop  results. 

Workshop  Background  & Goals 

The  purpose  of  this  workshop  was  to  bring  together  knowledge-based  system  (KBS)  developers,  vendors 
and  users  from  different  engineering  disciplines  to  discuss  matters  of  common  interest  concerning  software 
interoperability.  Functional  interoperability  is  fundamental  to  the  success  of  complex  engineering  processes 
such  as  collaborative  design.  Although  much  effort  has  been  put  forth  in  standardizing  geometric  product 
data  exchange  with  the  development  of  the  international  STandard  for  the  Exchange  of  Product  model  data, 
STEP,  ISO  10303  [IS094],  such  standards  do  not  yet  address  the  exchange  of  parametric  data  such  as 
design  rationale,  functional  specification  and  design  intent.  To  achieve  functional  interoperability, 
computer-aided  engineering  (CAE)  applications  in  general,  and  KBS  in  particular,  need  to  be  implemented 
in  such  a way  that  the  exchange  of  data  and  knowledge  can  occur  without  loss  of  information,  tolerance  or 
robustness.  How  to  bring  about  this  interoperation  is  precisely  the  reason  for  this  workshop. 

The  workshop  mission  was  to  provide  an  open  forum  for  KBS  vendors,  engineers  and  manufacturers,  to 
discuss  the  state-of-the-art,  identify  gaps  in  current  technology,  and  to  begin  proposing  solutions  to  close 
those  gaps. 

Specific  workshop  goals  include  the  following: 

• to  provide  an  overview  of  the  state-of-the-art  in  KBS  interoperability  issues  in  industry, 
government  and  academia, 

• to  present  industry  case  studies  on  current  practices  in  KBS  interoperability, 

• to  draw  roadmaps  that  will  aid  in  research  and  development  in  KBS  interoperability,  especially 
in  collaborative  engineering  projects,  and 

• to  identify  interoperability  standards  and  technology  issues. 

The  workshop  was  organized  as  a series  of  presentations  from  speakers  representing  KBS  developers,  KBS 
researchers,  and  engineers  who  use  KB  and  CAE  systems  in  their  design  and  manufacturing  activities  (two 
developers,  three  researchers  and  two  engineers).  NIST  personnel  provided  additional  input  on  the  state  of 
comparable  standards  and  government  activity.  Following  the  morning  of  presentations,  workshop 
organizers  split  the  participants  into  two  subgroups.  Each  subgroup  brainstormed  on  one  of  these  two 
themes: 

I-  State  of  the  Art  on  KBS  Interoperability 


1 Specifically,  this  workshop  was  sponsored  by  the  Engineering  Design  Technologies  (EDT)  Group,  a part  of  the 
Manufacturing  Systems  Integration  Division  (MSID),  under  the  auspices  of  the  Defense  Advanced  Research  Projects 
Agency’s  (DARPA’s)  Rapid  Design  Exploration  and  Optimization  (RaDEO)  program. 

2 

A KB  system,  also  known  as  an  expert  system,  is  software  that  has  some  knowledge  or  expertise  about  a specific, 
narrow  domain,  and  is  implemented  such  that  the  KB  and  the  control  architecture  are  separated.  KB  systems  have 
capabilities  that  often  include  inferential  processing  (as  opposed  to  algorithmic  processing),  explaining  rationale  to 
users  and  generating  non-unique  results  [Mah87]. 
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II-  Barriers  and  Requirements  for  KBS  Interoperability 

The  subgroups  reconvened  to  discuss  the  issues  raised,  and  report  on  each  subgroup’s  findings  to  the  entire 
workshop.  The  second  day  was  used  for  a general  discussion,  refinement  of  our  findings,  and  for  the  group 
to  agree  on  a list  of  action  items  to  be  taken. 


Workshop  Results 

Of  the  more  than  a dozen  issues  identified  by  the  groups  (and  listed  below),  two  main  themes  emerged: 

1.  Interoperability  among  KB  and  CAE  systems  is  a major  bottleneck  today. 


2.  Current  standards  do  not  address  many  of  the  interoperability  issues  associated  with  KBS. 

Within  these  main  themes,  five  concepts  emerged  as  priority  issues.  These  are: 

Characterization  There  is  strong  need  to  characterize  - perhaps  even  standardize  - the  capabilities,  behavior 
and  underlying  philosophy  of  KB  systems. 


Usability 

Vocabulary 

Collaboration 

Cost 


Engineers  and  manufacturers  who  use  KB  and  CAx  systems  must  not  be  unduly 
burdened  with  interoperability  issues. 

For  design  and  manufacturing  applications,  a core  set  of  primitives  (such  as  artifact, 
design  plan,  goal,  form,  function  and  behavior)  need  to  be  understood  and  represented  in 
a standardized  way  so  that  meaningful  exchange  of  such  knowledge  can  be  achieved. 

The  commercial,  academic  and  governmental  communities  must  collaborate  to  address 
the  interoperability  issues  in  a most  meaningful  way. 

The  cost  of  KB  systems  and  their  interoperability  must  be  manageable  for  midsize 
companies. 


Participants  also  identified  14  issues  as  being  important  in  KBS  interoperability.  These  are  listed  below: 


1.  Knowledge  representation  (KR)  is  the  critical  element  for  interoperability  because  if  different  KR 
schemes  need  to  interact,  there  must  be  some  commonality  among  representations.  One  possible  solution  is 
to  link  different  KR  schemes  by  using  the  Knowledge  Interchange  Format,  KIF  [Gen92],  with  a formal 
explicit  specification  of  a conceptualization,  often  referred  to  as  a frame  ontology  [McG93], 

2.  Mediation  is  important  for  interoperability  because  it  places  context  on  a specific  knowledge  base, 
otherwise  known  as  semantic  heterogeneity. 

3.  Problem  solving  cooperation  is  necessary  to  limit  the  amount  of  knowledge  sharing  in  specific 
interoperable  transactions. 


4.  Knowledge  base  validation  is  important  for  interoperability  because  of  the  consistency  issue  associated 
with  individual  KBs,  and  the  ramifications  for  downstream  propagation  of  possible  misinformation. 

5.  Negotiation  is  an  important  attribute  in  interoperable  KB  systems  because  of  the  nature  of  most 
engineering  design  and  manufacture  activities. 

6.  Knowledge  base  comprehension  is  important  for  global  context.  To  efficiently  interoperate,  KB  systems 
require  agents  that  describe  the  knowledge  a specific  KB  contains,  thereby  streamlining  search. 

7.  Knowledge  capture  is  clearly  achievable  for  specific  domains,  yet  this  activity  remains  a bottleneck. 


Summary,  Knowledge-based  Systems  Interoperability  Workshop,  2 


8.  Knowledge  history,  or  meta-knowledge,  is  important  to  trace  the  reason  for  a particular  conclusion  or 
action. 

9.  Knowledge  types  must  be  varied  for  interoperability  to  be  effective.  Many  types  of  objects  should  be 
recognizable  - business  objects,  design  objects,  management  objects  and  manufacturing  objects. 

10.  KIF  was  developed  as  an  interchange  format  and  may  prove  very  useful  as  a building  block  in 
representing  knowledge  across  different  KR  schemes. 

11.  Design  rationale  is  one  level  of  knowledge  that  must  be  made  interoperable. 

12.  Common  Object  Broker  Request  Architecture,  or  CORBA  [OMG96],  compliance  is  important  for 
communication  across  different  platforms  and  applications  implemented  in  different  languages. 

TM 

13.  Java  [Cam96]  compliance  may  be  important  for  distributing  knowledge  across  networks. 

14.  Problem  solving  method  libraries  are  important  so  that  meta-knowledge  can  be  used  to  locate 
appropriate  knowledge  sources. 

Action  Items 

The  workshop  concluded  with  a set  of  five  action  items  that  participants  agreed  to  address.  These  are: 

1.  Begin  surveying  KBS  developers  and  characterizing  existing  tools. 

2.  Develop  sample  practical  problem  involving  multiple  KB  and  CAx  systems. 

3.  Define  a taxonomy  of  domain  entities,  or  primitives,  that  lend  themselves  specifically  to  interoperability 
in  design  and  manufacture. 

4.  Explore  the  similarities  and  differences  between  KIF  and  the  STEP  data  modeling  language,  EXPRESS, 
and  its  extensions. 

5.  Draft  position  paper  on  KBS  interoperability  discussing  goals,  challenges,  strategies  and  areas  of 
application. 
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Workshop  Agenda 

Monday,  3 November  1997,  Shops  Building  (304),  Conference  Room 

8:00  - 8:30  Registration  and  continental  breakfast 

8:30  Welcome  to  NIST 

Richard  Jackson,  Director 

Manufacturing  Engineering  Laboratory  (NIST) 

8:45  KBS  Interoperability  in  Design:  A NIST  Perspective 
Ram  Sriram,  Leader 

Engineering  Design  Technologies  Group  (NIST) 

9:00  Overview  and  Workshop  Goals 
Robert  Allen,  IPA  Researcher 
Engineering  Design  Technologies  Group  (NIST) 

9:10  Knowledge-based  Design  Automation  and  Optimization  Systems  in  a Production 
Environment  - 
Siu  Tong, 

Engenious  Software 

9:35  The  ICAD  System:  A Generative  KB  Technology 
Prasanna  Katragadda, 

Concentra  Corporation 

10:00  Intelligent  systems  using  KB  Engineering 
Adel  Chemaly 
TechnoSoft,  Inc. 

10:25  Rule-Based  Interoperability  of  Heterogeneous  Systems 
Stanley  Su 

University  of  Florida 
10:50  Break 

11:15  Configurator  Synchronization 
Bruce  Ambler 
Lucent  Technologies 

1 1:40  OKBC:  A Programming  Foundation  for  KB  Interoperability 
Vinay  Chaudhri 
SRI  International 

12:05  Knowledge  Source  Awareness  models  for  Interoperable  KB  Systems 
Ramana  Reddy 
West  Virginia  University 

12:30  Lunch 
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1:30  Breakout  Group  Organization 

1:45  Breakout  Working  Groups 

State  of  the  art  in  KBS  interoperability 
Barriers  and  requirements  for  KBS  interoperability 

3:15  Break 

3:45  Joint  panel  discussions  of  BG  session  summaries 

4:45  Software  Demonstration 
Engenious  Software 

7:00  Social  Hour  and  Banquet,  Gaithersburg  Hilton 

Tuesday,  4 November  1997,  Bldg.  304  - Shops  Conference  Room 

8:00  Continental  breakfast 

8:45  Summary  of  Day  One  Results 
Robert  Allen 

9:00  Group  Discussion 

10:30  Break 

10:45  Summary  Discussion/  Action  Items  Identified/ Adjourn 
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Appendix  B 


Abstracts 


Issues  in  Deploying  Knowledge  Based  Design  Automation  and 
Optimization  Systems  in  a Production  Environment 

Siu  S Tong 

Engineous  Software,  Inc. 


This  presentation  describes  the  successes  and  difficulties  in  deploying  knowledge  based  design  automation 
and  optimization  systems  in  a production  environment.  Twelve  years  of  developing  and  implementing 
KBSs  at  GE,  and  three  years  experience  vending  software,  form  the  basis  of  these  observations  and 
conclusions. 

To  meet  the  industrial  challenge  of  drastically  reducing  the  product  development  cycle  and  cost  while 
maintaining  product  quality,  a new  software  system  was  developed  at  GE  Corporate  R&D  in  the  early 
1980s.  It  combined  traditional  mathematical  based  design  optimization  algorithms  and  modern  knowledge 
based  system  (KBS)  approaches  to  automate,  integrate,  and  optimize  engineering  design.  The  software, 
Engineous,  was  successfully  deployed  in  eight  of  13  GE  businesses.  In  the  past  three  years,  a redesigned, 
commercial  version  of  Engineous,  called  iSIGHT,  was  developed  and  tested  in  large  corporations  in  five 
major  industries  — aerospace,  defense,  power  & utilities,  automobile,  and  industrial  manufacturing. 

The  hybrid  knowledge  based  system  and  mathematical  approach  has  proven  to  be  useful  and  efficient  in 
solving  complex  problems  such  as  the  design  of  aircraft  engine  turbines,  power  generation  equipment, 
satellites,  transformers,  utilities  planning,  and  electrical  devices.  On  average,  this  technology  reduces  the 
design  cycle  time  and  manufacturing  costs  by  an  order  of  magnitude,  saving  tens  of  millions  of  dollars. 
However,  there  are  many  challenges  in  large-scale  deployment  of  this  technology  to  commercial  users.  The 
most  difficult  one  is  enabling  end-users,  not  knowledge  based  system  developers,  to  create  and  maintain  the 
knowledge  base.  The  existing  KB  systems  are  too  complex  for  most  engineers  to  learn,  and  developing 
complex,  practical  KBS  application  often  takes  too  much  time  and  effort.  Also,  there  are  many  CAD,  CAE, 
and  other  productivity  tools  (e.g.,  spreadsheet)  in  use  in  most  design  environments  and  substantial 
development  efforts  are  often  needed  to  link  these  tools  together. 

This  presentation  will  highlight  some  of  these  challenges,  discuss  the  successes  and  failures  in  working 
around  these  problems,  and  suggest  future  development/improvement  of  KBS  that  could  significantly 
increase  its  use  in  a practical  design  and  manufacturing  environments. 
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The  ICAD  System  - A Knowledge  Based  Generative  Technology 


Prasanna  Katragadda 
Concentra,  Inc. 


The  ICAD  System  is  a Knowledge  Based  Engineering  software  solution  used  by  world  class  manufacturers 
in  aerospace,  automotive  and  industrial  equipment  manufacturing,  such  as  Boeing,  British  Aerospace,  Pratt 
and  Whitney,  GM,  Ford,  Jaguar,  Lotus,  and  others,  to  automate  system-level  design,  product  design, 
tooling  and  product  configuration.  The  ICAD  System  uses  generative  technology  to  capture  and  apply 
generic  product  design  knowledge  - both  geometric  and  nongeometric  - which  includes  product  structures, 
development  processes  and  manufacturability  rules.  Companies  that  use  ICAD  greatly  trim  cycle  time, 
reduce  downstream  costs,  and  provide  a flexible  environment  in  which  to  process  engineering  change 
orders.  Ultimately,  ICAD  System  users  shrink  a good  portion  of  the  design  or  configuration  process, 
allowing  it  to  be  completed  in  significantly  less  time  than  nonusers. 

Recently,  the  ICAD  "vision"  has  grown  beyond  the  individual  engineering  effort.  Through  its  KBO 
(Knowledge  Based  Organization)  initiative,  The  ICAD  System  is  attempting  to  examine,  understand  and 
define  such  aspects  of  an  organization’s  "knowledge"  as  how  it  is  represented,  stored,  examined,  used, 
exchanged,  updated  and  refined. 

Recognizing  that  in  today’s  business  and  engineering  environment,  knowledge  without  means  of 
interchange  is  not  very  useful,  our  presentation  also  includes  anticipated  interoperability  issues,  such  as 
representation  and  access  methods  for  knowledge,  and  the  role  of  international  standards  in  facilitating 
these  tasks. 
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Rule-based  Interoperability  of  Heterogeneous  Systems  in  NIIIP 


Stanley  Y.  W.  Su 

Database  Systems  Research  and  Development  Center 
University  of  Florida 


Heterogeneous  information  systems  such  as  agent  systems,  knowledge-based  systems,  database  application 
systems  and  CAx  systems  generally  have  different  data  and  knowledge  representations  and  run  on  different 
operating  systems  and  dissimilar  computing  platforms.  To  make  these  heterogeneous  systems  inter- 
operable as  an  integrated  information  system  on  a local  or  wide-area  network,  one  popular  approach  is  to 
encapsulate  the  functionalities  and  data  of  these  systems  as  objects.  By  doing  so,  they  can  be  uniformly 
represented  and  processed  in  the  integrated  information  system.  This  approach  is  taken  by  the  Object 
Management  Group  (OMG),  which  introduced  CORBA  and  ORB  to  provide  the  architecture  and 
communication  infrastructure  for  the  interoperation  of  distributed  objects  through  method  activations.  In 
the  NIIIP  project,  distributed  objects  are  modeled  in  terms  of  1)  their  structural  properties  and  constraints 
using  the  international  standard  modeling  language  EXPRESS,  2)  their  methods  using  OMG’s  IDL,  and  3) 
their  knowledge  rules  using  an  event-condition-action-alternative-action  (ECAA)  rule  language  developed 
at  the  University  of  Florida.  The  ECAA  rules  capture  enterprise  business  rules,  policies,  security  and 
integrity  constraints,  and  other  rules  of  interoperation  associated  with  distributed  objects.  An  object- 
oriented  knowledge  base  management  system  (KBMS)  is  used  to  provide  the  following: 

1)  GUIs  for  modeling,  editing,  browsing,  and  graphically  querying  the  conceptual  model  of  an  enterprise, 

2)  An  object-oriented  query  language  OQL  for  accessing  and  manipulating  metadata  and  shared  data,  and 

3)  An  event  and  rule  server  to  provide  both  build-time  and  run-time  event  and  rule  services. 

ECAA  rules  are  pre-compiled  into  rule  code  which  are  incorporated  into  program  bindings  generated  by  an 
IDL  compiler  for  distributed  objects,  thus  achieving  "rule-based  interoperability"  over  an  ORB.  They  can 
also  be  stored  in  the  KBMS  and  triggered  at  run-time  when  the  enterprise  knowledge  base  is  accessed  and 
manipulated. 
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Configurator  Synchronization 


Bruce  Ambler 
Lucent  Technologies 

Lucent  Technologies  sells  complex  telecommunications  equipment,  where  much  of  the  equipment 
configuration  is  custom  designed  for  each  sale.  Engineers  configure  this  equipment  with  the  aid  of  two 
knowledge-based  systems:  the  first  is  a sales  configurator  the  second  is  a factory  configurator.  The  sales 
configurator  is  operated  by  sales  people  and  configures  the  product  to  a level  that  it  can  be  priced  and 
contracted.  The  second  cofigurator  is  executed  when  the  order  gets  to  the  factory  and  configures  the 
components  to  the  level  that  the  equipment  can  be  built. 

Because  changes  in  product  design  require  the  configurators  to  be  changed,  there  is  a need  for 
interoperability  between  a product  information  system  and  the  configurators.  The  configurators  must  be 
kept  in  synch  with  the  product  and  each  other  since  the  output  of  the  sales  configurator  is  the  input  to  the 
factory  configurator.  The  interoperability  requirements  include  an  event  notification  service  and  a data 
exchange  mechanism.  The  nature  of  the  data  exchange  depends  on  the  nature  of  the  knowledge  based 
system.  Rule  based  systems  require  different  information  than  constraint  resolution  systems. 
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OKBC:  A Programmatic  Foundation  for 
Knowledge  Base  Interoperability 


Vinay  K.  Chaudhri,  Adam  Farquhar,  Richard  Fikes,  Peter  D.  Karp,  James  P.  Rice 
SRI  International  and  Stanford  University 


Open  Knowledge  Base  Connectivity  (OKBC)  is  an  application  programming  interface  for  accessing 
knowledge  bases  stored  in  knowledge  representation  systems  (KRSs).  OKBC  is  being  developed  under  the 
sponsorship  of  DARPA’s  High  Performance  Knowledge  Base  program  (HPKB),  where  it  is  being  used  as 
an  initial  protocol  for  the  integration  of  various  technology  components. 

OKBC  is  a successor  of  Generic  Frame  Protocol  (GFP)  which  was  primarily  aimed  at  systems  that  can  be 
viewed  as  frame  representation  systems  and  was  jointly  developed  by  Artificial  Intelligence  Center  of  SRI 
International  and  Knowledge  Systems  Laboratory  of  Stanford  University. 

OKBC  provides  a uniform  model  of  KRSs  based  on  a common  conceptualization  of  classes,  individuals, 
slots,  facets,  and  inheritance.  OKBC  is  defined  in  a programming  language  independent  fashion,  and  has 
existing  implementations  in  Common  Lisp,  Java,  and  C.  The  protocol  transparently  supports  networked  as 
well  as  direct  access  to  KRSs  and  knowledge  bases. 

OKBC  consists  of  a set  of  operations  that  provide  a generic  interface  to  underlying  KRSs.  This  interface 
isolates  an  application  from  many  of  the  idiosyncrasies  of  a specific  KRS  and  enables  the  development  of 
tools,  such  as  those  currently  being  developed  at  SRI  and  Stanford. 
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Knowledge  Source  Awareness  Models  For 
Interoperable  Knowledge  Based  Systems 


R.  Reddy 

Concurrent  Engineering  Research  center 
West  Virginia  University 


Knowledge  Based  Systems,  by  definition,  depend  on  one  or  more  sources  of  knowledge  for  their  operation. 
In  a stand-alone  knowledge  based  system,  these  knowledge  sources  are  usually  “attached”  to  the  inference 
engine  - the  heart  of  the  knowledge-based  system.  With  the  emergence  of  the  World  Wide  Web  (W3)  as  a 
seamless  global  information  infrastructure,  it  is  now  possible  to  construct  problem  solutions  based  on  a 
collection  of  cooperating  knowledge  based  systems.  In  such  an  endeavor,  each  component  may  depend 
partly  on  the  knowledge  sources  associated  with  one  or  more  knowledge  based  systems  in  the  group.  This 
can  only  be  possible  if  these  component  systems  can  inter-operate,  insofar  as  they  can  exploit  each  other’s 
knowledge  sources.  Let  us  take  a simple  example  of  a case  where  two  members  of  a team,  each  using  an 
“expert  office  assistant”  program  wish  to  manage  scheduling  and  communications.  Each  system  depends 
on  its  own  knowledge  source  - say  an  address  book.  Unless  each  system  knows  about  the  existence  of  an 
address  book  and  deal  with  converting  each  other’s  formats  to  their  own  representation,  they  can  never 
cooperate  - because  they  can  not  inter-operate.  To  overcome  this  problem,  the  following  characteristics  are 
needed: 

1 . A classification  system  for  various  types  of  knowledge, 

2.  A means  for  transforming  one  representation  into  another  (perhaps  using  an  intermediate  canonical 
representation),  and 

3.  A meta- model,  which  may  be  used  by  each  knowledge-based  system,  to  discover  the  needed  source 
from  the  domains  of  the  co-operating  systems. 

This  talk  provides  some  plausible  scenarios  for  dealing  with  the  above  imperatives. 
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Appendix  C - Presentation  Slides 


Issues  in  Deploying  Knowledge  Based  Design  Automation  and  Optimization 
Systems  in  a Production  Environment 


Siu  S.  Tong 

Engenious  Software,  Inc. 
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The  iSIGHT  CAO  Environment 
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Optimization  Algorithms  in  iSIGHT 
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Use  only  the  flowpath  parameters  as  design  variables 

If  the  flowpath  shape  has  been  optimized  then 
Add  the  remaining  design  variables  to  the  problem 


iSIGHT  Directed  Heuristic  Search 


CO 

3 

O 

CD 


CO 

N 


Tj  m 
CD  -E* 
CO  C 
CO  CD 


CD  ■== 

E a) 

.2  £ <5 

5 = 5 

2 2^ 

c o>o 

^ TO  03 


£2 
a> 

<d  a> 


£ hi  -j= 


s 

CO 

■ iTBBI 

CO 

To 

a. 

3 

g- 

cr 

CD 

CO 

CD 

CD 

.Q 

■ HBB 

CD 

o 

-Q 

CO 

CO 

CD 

C 

T5 

O 

■ ■■ 

CD 

CO 

■*7?  - CO 

><  o 

CO  a> 
a>  m— 

<o  « 

5 m 

6 i 


< 5 
a>  o 
c c 

'c/> 

CO  ^ 
CD  C 

O o 


O) 

3 

O 


o 

CO 

CD 

CO 


CO 


CO 

o i 

CD 


m 

O) 

"5> 

CO 

o 

CD 

o 

a5 


CD 

O) 

c 

CO 


CD 


5?  O 

CD  "co  - 
CO  CD 


a 

o 

) fnn  Ijj 

* 

■S 

C/5 

a 


o 

N 


<D 

’5b 

c 

W 

a> 


• • 
a 

o 

• ps| 

ts 

o 

u 

Oh 

<3 


O 

■O 

a> 

■a 

a> 

CD 

© 

o 

ro  CD 
m ^ 

E CD 

CD  Q) 

o .Si, 


CO 

CO 

CD  "O  Q 

£ a>  .c 
<o 

cf  CD  S 

g s>  ; 

■■s:  o E 
co  c .2 


cc 


as 


co  -c 

o -tz 

Q 5 

CO  "O 

w a> 
o = 

"co  SS 

£ <2 


E £ 

03 

N 

■ HOT 

CD 

E 

"-B  CO 

g-j 

E 

■ mtmm 

-S  to 

Q. 

■ ■■ 

CO  CO 

o 

CD 

O 0) 

■ ■■  „ ||J||77| 

"CD 

£ 

"cD  -g 

E -g 

O 

■ ■n 

"co 

"co 

Qj  CD 

E 

CD 

■ m 

CD  C, 

-f 

f 

E .5> 

"co 

CD 

o 

■ BBM 

r-  <0 
±3  CD 

E , 

O) 

■o 

iZ  °° 
T "TO 
J-  m 

a > 

CO  CD 
— CO 


"O  CD  o 
CD  (/) 

O 5 . 


03  o 

Q 
CD 


CD 

a> 


I 

■ ■ 

■aa  ■ ■■ 

o 

CD  *- 
C CO 

& 

E 

CD 

CD  CO 

E = 

<5 

CD 

■ ■ BH 

0)x: 

c 

a 

o3  1 

X I 

W 1 

-Q 

O 

CL  CD 

w n wr-rm 

OTM  ■ 3BE3 

c 

1H 

O) 

<i>  q> 
CD  T3 

ol 

■ 

O'  ^ 
CD  ^ 

■ 

CD 

■C  -O 
1—  CD 

■ 

£ 

o 2 co 


£ 

co 

o 


thousand  pounds  per  aircraft 


CD 

O 

CO 

Ql 

CO 

-2 

o> 

■ Hi 

"co 

"O 

CO 

■i 

CD 

o 

"3 

CD 

c 

3 

o 

CO 

E 

CD 

CO 

o 

CD 

Q. 

■ nm 

X 

CO 

CD 

CO 

* 

CO 

CD 

E 

CO 

3 

-£ 

CD 

a hhi 

£ 

■*""» 

CO 

CO 

CO 

CO 

CD 

CD 

o 

o> 

ID 

CD 

o 

Q. 

£ 

CO 

O 

CO 

CD 

c 

CL>  (0 

3 O 
Q.  Z 
CO 

o 1 


CD 

CO 


D> 

CO 

CD 


CD 

W 

■ HH 

E 

CL) 

"co 

CO 

CD 

CO 

CO 

.Q 

CD 

CT> 

73 

_0> 

£ 

o 

E co 

<]>  <D 

* 1 o 

O £ 

CD  ^ 

^ CD 
^ D)  - 

3 -g  £ 

£>  £ = 
■=  9 w 


as  “■ 

<D  CD 

-J  co 

1 5 


co 


Capture  existing  design  knowledge 
- Some  early  successes 


Issues 


O "O 

»=  a> 

<0  -TT 

a>  s 
to  o 


CD 


o < 

0 j 

<u  < 
to  < 

1 

o t 


to  CO 
to  to  <i> 

UJ  111  f 


E o 

as  oo 
<D  ‘r 


a> 


CD 


as  q> 
£ > 


to 

to 

a> 

to 

to 


<D 

CD 

T3 

G)  to 

i i 

= » 

O w 
**  c 
to  d) 
to  a> 

tu  > 

o £ 

O CD 

to  _Q 


tD  0) 

.M  W 


CO 


CO 


£ CD 
tO  CD 

W "g 

Jg-i 

o o 
as  c 


- Hardwired  CLIPS  to  iSIGHT 

- Hardwired  interface  to  other  rule  systems 


Appendix  D - Presentation  Slides 


The  ICAD  System:  A Generative  Knowledge-based  Technology 


Prasanna  Katragadda 
Concentra  Corporation 
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The  ICAD  System 
& 

I.C.E. 

Product  Overviews 


Prasanna  Katragadda 
Director  of  Operations,  The  ICAD  System 


Let’s  define  some  terms  . . . 
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Knowledge-Based  Engineering  (KBE) 

A methodology  for  capturing  the  knowledge  about  a process  and 
applying  it  to  solve  engineering  problems. 

Dataquest: 

“KBE  Tools  - tools  used  to  capture  design  intent  and  build  standard 
practices  for  controlling  and  modifying  design  and  manufactring 
activities.” 


Let’s  define  some  terms  . . . 


♦ Generative  Technology 

Concentra’s  implementation  of  KBE  which  enables  companies  to  capture  and  automate  the 
way  engineering  practices  are  performed  generating  new  designs  directly  from  functional 
requirements  in  minutes  not  months. 

♦ The  1CAD  System 

The  name  of  Concentra's  engineering  product  which  incorporates  Generative  Technology 
and  is  used  to  create  a Generative  Model. 

♦ Generative  Model 

The  actual  application  created  when  applying  Generative  Technology  with  The  ICAD 
System  to  model  an  engineering  process. 
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Concentra ’s  Generative  Technology  provides  the 
underlying  foundation  for  application  development 


The  ICAD  System 


♦ Enterprise  Fit 

♦ Customizable  Layout 

♦ Object  Oriented 

♦ Scalable  Structure 

♦ Open  Architecture 

♦ Standards  Compliant 


Customers  Generate  Designs 
from  Functional  Requirements 


Inputs 

Size,  Performance, 
Cost,  Appearance, 
Durability  ... 


Outputs 

Drawings,  3-D  Models, 
Bills  of  Material,  Cost 
Proposals,  Tool  Design 


System  Configuration 


Building  a Generative  Model  ... 


Production  Environment 
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...  and  using  a Generative  Model 


Unique  capabilities  of  Generative  Technology 


Multiple  Topology  Generation  Geometric  Problem  Solving 


Multiple  Topology  Generation  - 

Many  designs  from  a single  generative  model . . ♦ 
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Horsepower 

4 

RPM 

200 

Input  Shaft  Dia. 

1.0” 

Output  Shaft  Dia. 

1.0” 

Inputs 

Horsepower  2 

RPM  400 

Input  Shaft  Dia. 

Output  Shaft  Dia. 


Multiple  Topology  Generation  - 

Many  views  associated  with  a single  design  . . . 


Full  Associativity  between  all  views  of  the  design 


C O N'  C.  r.  N T k.  A 


Driving  Product  Design  With  Analysis 


Transmission  Gearboxes 


♦ Generative  Model  drives  a series  of  stress  analysis  programs. 

♦ Design  time  reduced  from  3 weeks  to  less  than  one  day.  ^ 


Generating  Data  for  the  Manufacturing  Process 


Solid  Model  Geometry 
for  tool  path  generation 


Assembly,  Detail, 
Schematic  drawings 


Unique  capabilities  of  Generative  Technology 


>/  Multiple  Topology  Generation  allows  a single  generative  model  to 
associate  and  drive  multiple  design,  assembly,  analysis,  and 
manufacturing  views. 

l/  Geometric  Problem  Solving  provides  the  ability  to  solve  the  difficult 
geometric  design  problems  insuring  proper  form,  fit,  and  function. 

%/  Analysis  Driven  Design  provides  the  tools  to  integrate  and  drive  the 
model  with  analysis  programs. 

\/  Generative  Manufacturing  Data  means  feeding  downstream 

processes  with  the  required  information  necessary  to  make  the  part. 


Benefits 


♦ Reducing  time  to  market 

>-  through  process  automation 

♦ Improving  product  quality 

>•  through  integration  of  functional  requirements  (IPD) 

♦ Reducing  costs 

> through  minimizing  design  changes 

♦ Facilitating  technical  memory  retention 

> through  design  practice  and  process  capture 


Concentra  in  Aerospace  - Making  Concepts  Fly 

♦ Leaders  in  aircraft  manufacturing  realizing  dramatic 
design  cycle  time  reductions. 

> Boeing 

> Aerospatiale 

> British  Aerospace 


Boeing  111  - New  Longer  Range  Plane 


Inputs 
Mission  Rqmts 
Part  Location 
Aerodynamic  Surfaces 
Structural  Loads 
Skin  & Rib  Geometry 


“B  Market  Plane” 


Outputs 

20,000  New  Wing  & Fuselage  Parts 
Stringers,  Shear  Ties,  Stringer  Clips 
Wing  Ribs,  Skins,  Spars  ... 

(3D  Solid  Models,  Drawings  & Reports) 


Cycle  Time  Reduction  Achieved 


Results: 

♦ $20  benefit  for 
each  $1  invested 

♦ One  million 
engineering  hours 

♦ Total  savings  over 
$40  million 


Cycle  Time  Reduction  Achieved 


Results: 

♦ Tooling  Design  Cycle 
time  Reduced  93% 

♦ 9 Month  Payback 

♦ ROI  = 280% 

♦ ECO’s  dramatically 
reduces 


Concentra  in  Automotive  - From  Zero  to  Concept  in 
Record  Time!  

♦ I.C.E.  is  an  ICAD  Application 

♦ Designed  for  Automotive  Manufacturers  & Suppliers 

♦ Automates  the  Conceptual  Design  Process 

> A Very  Manual  Process  Today 

> CAD/CAM  Tools  Not  Sufficient  This  Early  in  the  Design 

♦ Feasibility  Studies  Now  Much  Quicker  and  Easier 

> Knowledge  Base  of  your  Best  Engineers 

> Relevant  Legislation  and  Design  Codes 

> Manufacturing  Rules 

♦ Months  to  Minutes  is  REALLY  working! 


The  vehicle  development  process  commits  80%  of 
cost  during  the  conceptual  design  phase 


Conceptual  Detailed  Tooling  Mfg. 

Design Design Design 


To  meet  these  challenges  car  makers  must 
balance  many  different  disciplines 


The  I.C.E.  Berg 


A cleaner  upfront  vehicle  design  will  further 
compress  vehicle  development  schedules  ... 


-5  Yrs 

Achievatlte- 


■4  Yrs 

I 


-3  Yrs  -2  Yrs  -1.5  Yrs  Job  #1 

-J I I I I ■> 


Benefits  of  I.C.E. 

♦ Frees  the  creative  spirit! 

♦ Drives  the  process  from  the  highest  level,  the  Concept 

♦ Enables  delayed  decisions  (Ref  Toyota  Second  Paradox) 

♦ Multiple  iterations  improves  quality 

♦ Skills  and  best  practices  ‘baked  into  the  process’  (Right 
first  time,  consistency,  retention  of  ‘design  intellect’  etc) 

♦ Collapsed  timescales 

^.easily  the  fastest  route  from  Concept  to  Design  Freeze  Point 


Delivering  Engineering  Knowledge  to  the 
Enterprise 

Positioning  Engineering  Companies  for  the 
21st  Century 


Current  Realities  in  Manufacturing  Companies 

♦ Competitive  edge  is  driven  by  process  dominance  rather 
than  technology  prominence 

♦ Customer  dictated  markets  require  flexible  engineering 
and  manufacturing  capabilities 

♦ New  product  development  projects  typically  leave  poorly 
understood,  tangled  and  inefficient  engineering  and 
manufacturing  processes 

♦ IT  technologies  have  been  only  marginally  effective  at 
improving  product  development  process 

♦ Downsizing  has  become  the  dominant  management 
approach  for  controlling  expenses 


The  Downsizing  Paradox 
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♦ Knowledge  is  the  key  asset  for  the  corporation 

♦ Today,  a companies  knowledge  assets  are  embodied  in 
its  employees 

♦ Employees  no  longer  expect  to  spend  more  than  a few 
years  at  one  company 

♦ Knowledge  assets  are  extremely  volatile 


Characteristics  of  Successful  Product  Development 

♦ Maximizes  reuse  of  company  knowledge 

♦ Maximizes  use  of  “Best-Practices” 

♦ Takes  full  advantage  of  automation 

♦ Allows  flexibility  and  customization 

♦ Provides  a manageable  legacy  of  artifacts  and 
technologies 


Product  Development  Strategies 
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♦ A winning  strategy  must  link  together  three  key  elements 


Virtual  Enterprises  for  Product  Development 

♦ A Virtual  Enterprise  is  a collection  of  company  resources  and 
knowledge  which  are  orchestrated  together  to  produce  a given 
product  offering 


Customer 

Requirements 


Product 

Deliverables 


\ 


Company 

Knowledge 


Company 

Resources 


A Modular  Product  Development  Strategy 


Knowledge  Packets 


♦ A fundamental  package  of  stable  company  knowledge 


Engineering  Knowledge  Backbone 


♦ A flexible  framework  for  knowledge  integration  and  artifact 
generation 


External 

Knowledge 


Engineering  Knowledge  as  a Competitve  Weapon 

♦ The  legacy  of  the  past  50  years  has  left  engineering 
companies  with  core  competancies  based  on  engineering 
knowledge 

♦ Product  development  strategies  hinge  on  being  able  to 
deliver  the  right  knowledge  to  the  key  product  engineers 
when  they  need  it 

♦ Capturing  Engineering  Knowledge  requires  a language 
built  around  Engineering  Objects 

♦ Sharing  Engineering  Knowledge  requires  an  architecture 
which  supports  Knowledge  delivery  across  the 
organization 


Concentra’s  Future  Role  in  the  Virtual  Enterprise 

♦ Knowledge  Packets  are  stored  in  the  Knowledge 
Repository 

♦ Knowledge  Server  exposes  Knowledge  Packets  as 
Components  (Corba  Objects) 

♦ External  engineering  knowledge  contained  in  other 
systems  can  be  integrated  by  exposing  them  as 
Components 


Knowledge  Interoperability 

(A  discussion) 


Ish  Deif 

Principal  Engineer,  The  ICAD  System 


No  one  has  all  the  knowledge 

Even  if  we  developed  a virtual  Isaac  Newton,  he’d  only 
discover  Newtonian  mechanics... 


We’d  still  need  to  develop  a virtual  Einstein  to  discover 

relativity! 


Knowledge  Interoperability 

First,  data  sharing  became  important 
Next,  information  sharing  became  crucial 
Now,  Knowledge  sharing  is  essential 
Guiding  Principle: 

The  whole  is  greater  than  the  sum  of  its  parts 


Knowledge  Interoperability:  What 


♦ Domain  of  knowledge  to  capture  and  represent 

> Engineering  knowledge 

> creation  of  geometric  entities 

> code  checks 

> Manufacturing  knowledge 

> manufacturing  processes 

> routings  and  tooling 

> Business  knowledge 

> efficiencies  of  scale 

> labor  and  manufacturing  costs 

> Other  types  of  knowledge 


Knowledge  Interoperability:  How 


♦ Means  of  knowledge  representation 

> Language(s)  rich  enough  to  capture  targeted  knowledge 
domains 

> Knowledgebases  (Databases  holding  knowledge) 

♦ Means  of  knowledge  interchange  and  access 

> File  transfer  mechanisms 

> Knowledgebase  access 

> Embedded  systems 

> Distributed  objects 

> Intelligent  agents 

y Knowledge  packets 


Knowledge  Interoperability:  Who 


♦ Mechanisms  for  recognition  of  knowledge 

> Automatic  browsing  mechanisms 

> Standard  representation 

> Standard  interfaces 


Knowledge  Interoperability:  Issues 


♦ Maintaining  existing  interfaces 

> Browsing  and  smart  clients  can  help 

> Intelligent  agents 

>can  use  translation  facilities  to  talk  to  client  in  client’s 
own  language 

♦ Extending  knowledge 

> How  to  extend  existing  knowledge  domain 

> How  to  add  knowledge  for  new  applications 

> How  to  integrate  old  and  new  knowledge 


Role  of  Knowledge  Standards 


♦ Define  knowledge 

► What  constitutes  “knowledge”  in  a particular  domain 

► Knowledge  as  based  on  application 

(Knowledge  of  how  to  design  is  different  from  knowledge 
of  how  to  manufacture,  how  to  use,  etc.) 

► What  capabilities/interfaces  to  support 

♦ Define  means  of  access  to  knowledge 

♦ Universal  language 


Knowledge  Interoperability:  Present  and  Future 

♦ Present 

► CORBA  and  COM 

► SDAI 

♦ Future 

► Declarative  knowledge 

► Inferred  procedures 

► Knowledge  marts 

►“Lease  your  expertise” 

► Cooperative  approaches  to  solving  problems 

►Virtual  engineers  using  knowledge  packets 

► High-level  problem  descriptions 
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Intelligent  Systems 
using  Knowledge  Based  Engineering 


Xtechno  S oft  Inc. 
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TADS/PNVS 


Javelin 


Navy/ 
Air  Force 
JAST 


ARPA  MADE 
(Gimbal  Design) 
ARPA 
RASSP 


EO/1R 

Seeker  and  Sensor 

AHPA 
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RaDEO-IGD  Program 


Deliverables 


Lockheed  Martin 
GimbalS 
Optical  Design/ 

. Mamrfacturing 


Application 

Software 


UCF 

MCAE  Software 
Development 


'Coleman  Research 
Expert  System 
Missile  Design. 
l Component 
m^Layaries 


FAMU 

STEP, 

Distrfcuted 

.Databases 


PATRAN 


Master 

Series 


MSC/ 

NASTRAN 


MADE:  Development  of  Adaptive  Modeling  Language  for  Knowledge-Based 
Engineering  with  Application  to  Interactive  GimbaJ  Design 


MATRIX-X 


IGD  Interactive 
Gimbal  Design 
System 


GimbaJ 

Components 

Library 


Knowledge- 
Based 
Engineering 
AML  Paradigm 


FEM/ 

SfNDA 


MQO [tfcer  itemed 
**G0  Technical  M 


M-VISION 


Distributed  STEP  Database 


Functional  Capability  of  the  IGD  System 
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The  Gimbal  Design  Process 


Product  Design  Process 
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Gimbal  Design  Statistics  of  a Missile  System 


’All  data  in  this  table  has  been  multiplied  by  the  same  constant  factor  in  order  to 
protect  proprietary  information. 
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Basic  Structure  of  the  IGD  System 


Manu- 

facturing 

Proces- 

ses/Cost 
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Require- 
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Design 


Visuali- 
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Optical 

Design 
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Basics  of  the  IGD  System  Part  Models 


CONCEPTUAL  MODEU 


PRELIMINARY  MODEL 


DETAILED  MODEL 
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OBJECTIVES 


Organize  the  vital  engineering  knowledge  and  expertise  to 
integrate  and  automate  the  entire  gimbal  engineering  cycle 
from  conceptual  design  to  production 


Development  of  an  Interactive  Gimbal  Design  (IGD)  System 
based  on  AML  that  will  capture  the  gimbal  design  process 
followed  at  Lockheed  Martin.  The  IGD  structure  will  allow 
for  a creative  design  environment  and  capture  the  knowledge 
of  that  creativity. 
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IGD’s  Part  Model  Representation 


Part  Model 


The  design  strategy  is  captured  within  a 
part  model,  represented  by  a hierarchy  of 
objects,  that  reflects  the  design  intent  and 
the  strategy  of  various  engineering 
processes. 
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Knowledge  Based  System  for  Optical  Design 


Design  Iteration 


TECHNOSOFT  12 
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Optical  System  Objectives 

♦ Dynamic  link  between  ACCOS-V  and  AML  IGD 

♦ Read  ACCOS-V  “LENO”  files  (legacy  data) 

- Converts  ACCOS  LENO  to  AML  Optics  Analysis  Model 

- Allows  use  of  legacy  data  and  analysis  strategy 

♦ Writes  ACCOS-V  “LENO”  files 

- Translates  AML  data  to  valid  ACCOS-V  format  data 

♦ Performs  parameter  lookups 

- Requests  data  from  ACCOS-V  for  solve  data 

♦ All  ACCOS-V  analysis  is  available  without  reinventing 
analysis  in  AML 
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Optical  Design 

Thin  Lens  Design 


Design  Iteration 
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Optical  Design 


Thin  Lens  Design  Example 
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Optical  Design 


Thin  Lens  Example: 
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Optical  Design 


Thin  Lens  Folded: 
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Optical  Design 


Thin  Lens.  Suppressed  Fo!d: 
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Optical  Design 

Thin  Lens  Design:  AML  - Optics  Object  Tree 
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Optical  Design 

Detailed  Lens  Design 


Design  Iteration 
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Optical  Design 

AML  ACCOS-V  Optical  Design  Scenario: 

AML  illustrates  an  ACCOS-V  LENO  (legacy  file  being  read  in  and  the  resulting 
graphical  display  confirming  this.  Note  GUI  for  AML  optics,  ACCOS-V,  and 
various  functional  capability. 


22 
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Optical  Design 

AML  ACCOS-V  Optical  Design  Scenario: 


An  ACCOS-V  command  has  been  issued  in  AML  that  evaluates  the  optical 
prescription  in  ACCOS-V  and  then  displays  the  results  in  AML.  A ray  bundle  has  also 
been  traced  through  all  surfaces  automatically  in  ACCOS-V  and  displayed  in  AML. 


Domed 

Window 


Secondary 

Mirror 


Primary 

Mirror 


FPA 


Lenses  (3) 
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Optical  Design 


AML  ACCOS-V  Optical  Design  Scenario: 


The  AML  ACCOS-V  optical  system  illustrates  a 3-D,  dynamically  rotatable 
view  of  the  design.  A lens  cell  has  also  been  generated  by  the  system. 
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Optical  Design 

AML  ACCOS-V  Optical  Design  Scenario: 

Close-up  of  the  lens  area  illustrates  the  lens  cell.  Note  the  functionality 
offered  in  AML  allows  for  a lens  spacer,  retainer,  and  seats.  At  any  time, 
additional  ray  traces  can  be  served  from  ACCOS-V  to  check  for  vignetting. 


26 


11/2/97 


TECHNOSOFT 


Optical  Design 

AML  ACCOS-V  Optical  Design  Scenario: 

With  the  lens  cell  removed,  a close-up  illustrates  the  three  lens.  Adjustments 
to  manufacturing  features  can  be  made  at  any  time. 
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Optical  Design 

Qualitative  Metric:  Assessment  of  Detailed  Optical  Design 


Six  senior  optical  designers  were  presented  an  overview  and  demo  of  the  AML 
ACCOS-V  detailed  optical  design  capability  (as  illustrated  here).  The  following 
table  summarizes  their  projected  impact  of  the  AML  ACCOS-V  detailed  optical 
design  sub-system  of  the  IGD.  A fully  integrated  IGD  System  of  the  multi- 
disciplinary gimbal  design  process  was  not  assessed  by  this  group. 


Dented:  Optical  Datflgrt 

% 

% Improvement 

In  Design  Time 

% Improvement 
in  Design  Capability 

% 

% Improvement 
in  Analysis  Time 

% ol  Analysis  that  can 
be  dona  more  rigorously 

50% 

These  projections  are  tor  detailed  optical  design,  not  conceptual  design. 
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Mechanical  Design 

Gimbal  Test  Bed  System:  Used  for  Proof-of-Concept  Modeling 
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Mechanical  Design 


Flow  of  data  from  1GD  showing  DADS 


Matrix-X  Simulation 


- Interactive  control  of  application  from  IGD 

11/2/97 


TECHNOSOFT 


IMPACT 


Applicability  of  the  RaDEO-IGD  KBS  : 


• The  RaDEO-IGD  system  is  primarily  a preliminary  design  tool  with  ties  to 
manufacturing.  80%  of  a missile  system  costs  are  committed  in  the  first  20% 
of  the  program.  The  IGD  system  is  a “direct  hit’’  at  this  early-on  design  phase. 
The  IGD  system  integrates  final  design  software  tools  thus  allowing  for  an 
efficient  transfer  of  effort  from  preliminary  design  to  detailed  design. 

• The  Seeker/Gimbal  component  of  a missile  system  contribute  to  60-70%  of 
the  cost  of  a missile  system.  The  RaDEO-IGD  System  is  a “direct  hit”  to  attack 
this  high  cost  area. 

• While  the  DARPA  RaDEO  program  in  general  and  the  IGD  system  in  particular 
does  not  focus  directly  on  cost  (10  fold  increase  in  design  space),  AML  class- 
objects  have  been  developed  to  predict  manufacturing  costs.  This  capability  is 
integral  to  AML  and  can  be  readily  applied  to  the  missile  systems. 

• The  RaDEO-IGD  System  and  associated  gimbal  sub-components  database  is 
directly  applicable  to  missile  systems. 
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Rule-Based  Interoperability  of  Heterogeneous  Systems 

Stanley  Su 
University  of  Florida 
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Rule-based  Interoperability  of 
Heterogeneous  Systems  in  the  NIIIP  Project 

Outline 

• NIIIP  Reference  Architecture 

• Inter-operation  of  Distributed  Objects 

• Event-Condition-Action-Alternative-Action  Rules 

• Events  and  Event  Model  in  CORBA 

• Rules  Triggered  by  Events 

• Event  Server  and  Rule  Server  implementation  Approaches 


Nam 


Inter-operation  of  Distributed 
Objects  by  Method  Invocations 


wrapper 


wrapper 


ORB 


workflow  Agent 

with  rule  sys 


Desktop  Mediator 


Inter-operation  of  Distributed 
Objects  Defined  in  ECAA  Rules 


Nom 


Workflow  Agent  ECAA  Desktop  Mediator 

with  rule  sys  rule  Sys 


Examples  of  EC  AA  Rules  for 
Data  and  Data  Access  Constraints 

• Security  rule: 

Event:  Before  retrieving  data  from  a file 

Condition:  If  the  user’s  access  privilege  is  not  sufficient 
Action:  Reject  the  access  request  and  initiate  actions  to 

report  and  handle  the  security  break 

• Requirement  rule: 

Event:  After  an  order  has  been  placed 

Condition:  If  QuantityOrdered  < OrderedProduct.StockLevel 

AltAction:  Abort  transaction  and  notify. 

• Computation  rule: 

Event:  After  an  order  has  been  placed 

Action:  OrderedProduct.StockLevel  = 

OrderedProduct.StockLevel  - QuantityOrdered 

• Cascaded  Update/Delete  Rule 

Event:  Update  part  or  supplier’s  identification  number 

Action:  Update  the  corresponding  number  in  the  Part-Supplier  instances 


Examples  of  EC  AA  Rules  for 
Controlling  Distributed  Objects 


Event  MES  foreman  determines  that  machine  is  down 
Condition:  If  machine  type  is  X or  Y and  an  Agent  for  repair  is  available 
Action:  Call  the  agent 

AltAction:  MES  ships  a work  location  status  reference  object  to  MS/FS  & CA 


► Event: 
Condition: 
Action: 
AltAction: 


The  engineering  change  status  has  been  changed  to  “initiated” 
If  it  is  a part  used  in  a government-supported  project 
Initiate  a “govemment-EC”  workflow 
Initiate  the  regular  EC  workflow 


► Event: 
Action: 


MS/FS  received  work  location  status  reference  object  from  MES 
MS/FS  issues  a re-plan;  MS/FS  triggers  a manufacturing  order  to  ERP; 


* Event:  Before  MEX  issues  a re-plan 

Condition:  A planning  assistance  agent  is  available 
Action:  Call  the  agent  to  generate  data  for  re -plan 


mam 


Some  Properties  of  an  ECAA  Rule 


Rule  <rule_id> 

Triggered  <coupling  mode>  <method_call  >1  <post_event> 
Priority  <integer> 

Condition  <guarded_expression> 

Action  <operations> 

Otherwise  <operations> 


Extensions: 


• An  event  can  trigger  a structure  of  rules 

• A rule  or  rule  group  can  be  dynamically  activated  or 
deactivated 

• Static  rules  are  pre-compiled  and  dynamic  rules  are 
interpreted 

• Events  can  be  posted  synchronously  or  asynchronously 


Object  Model 


NIIIP 


Ob)ec.t_Specification  in  EXPRESS  Method  Specification  in  IDL 


DEFINE  ENTITY  entity_id 
SUPERTYPE  OF  (supertype_expression) 
SUBTYPE  OF  (subtype  list) 
attrjd:  [OPTIONAL]  base_type 

DERIVE 

INVERSE 

UNIQUE 

WHERE  rulejabel:  rule  expression 
END.DEFINE; 


METHODS: 

EXCEPTION  exception_id  (var  : type;..) 


METHOD  [ONEWAY]  methodjd 
([IN  I OUT  I INOUT]  para_id:  para_type;  ...) 
[RAISES  (exception_id,  . . . )] 
END_METHODS; 


Rule  Specification  in  UFs  Rule  Language 

RULES: 

RULE  rule_id 

[TRIGGERED  triggered_time  trigger_operation,  ...] 
[PRIORITY  integer] 

[CONDITION  guarded_expression] 

[ACTION  statement_list] 

[OTHERWISE  statement_list] 

END_RULES; 


Why  Rules? 


• Implementation  of  a method  should  perform  only  its  intended 
function. 

• Semantics  of  the  pre-condition  and  post-condition  should  not 
be  embedded  in  the  implementation  code  of  the  method. 

• Instead,  they  should  be  explicitly  specified  as  ECAA  rules  to  augment 
the  interface  definition  of  the  class. 

• Change  in  business  rules  affect  only  the  ECAA  rules,  not  the 

method  implementation. 

• High-level  declarative  rules  are  easier  to  understand  than  program 
code. 


What  can  we  do  with  these  ECAA 
rules? 


• Generate  in-line  code  for  some  existing  applications 

(e.g.,  embedding  rule  code  into  implemented  Java  program 
in  the  CIIMPLEX  project) 

• Generate  program  bindings  for  linking  to  some 
existing  application  systems  or  agents 

(e.g.,  CORBA-bindings  for  rule-based  interoperability 
demonstrated  in  the  NIIIP  project) 

• Enforced  by  a centralized  or  distributed  rule  processing 
system  at  run-time 


Triggering  Events 


Meaningful  Triggering  Events  in  CORBA: 

• Method  invocation 

• Explicitly  posted  COSS  events 


Event  Model 


Supplier 


. data 


Event  Channel 


Supplier 


Consumer 
* 

* 

* 

* 

* 

Consumer 


ECAA  Rules  Triggered  by 
Events 


Rule  1 1 (possible  action) 
Rule  12  (possible  action) 

Rule  lm  (possible  action) 

Rule  jl  (possible  action) 
Rule  j2  (possible  action) 

Rule  jn  (possible  action) 


triggers 

event(i)  ► 

triggers 

event(j)  > 


Implementation  Approaches 


• Centralized  event  and  rule  servers 

• Distribute  event  monitoring  and  rule  code  to  distributed 
objects  by  enhanced  binding 

• Distributed  event  and  rule  servers  in  each  computing 
system 


Centralized  Event  Sever  and 
Rule  Server 


Enhanced  Bindings  for 
Distributed  Objects 


Server 

Client 

Enhanced  ■ 

Actions  triggered 
by  ECAA  rules 


Comm.  Infrastructure 


• Enhanced  bindings  for  compiled  and  distributed  event  monitoring 
and  rule  processing. 

• Enhanced  bindings  = 

“normal”  IDL  binding  + generated  code  for  event  monitoring 

and  rule  processing 


Distributed  Event  & Rule  Servers 
In  Computing  Systems 


Computer  A 
AL_ 


Computer  B 


Event  Server  Rule  Server 
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ElRules 

E2Rules 


(Communication  Infrastructure) 


Computer  C 
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Event  Server 
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posl(l) 


Event  Server 
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MXEvent 
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Value-added  Information  Infrastructure  for  Integrating 
Heterogeneous  Systems 

• Rule-based  Interoperability:  Extension  of  OMG/ORB 

• Semantics-rich  Object  Model:  Extension  of 
STEP/EXPRESS  and  OMG/IDL 

• Active  Integrated  Information  System 
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Configurator  Synchronization 

Bruce  Ambler 
Lucent  Technologies 
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Interoperability  with  Knowledge 
Based  Systems 

• Product  Configurators 

- Purpose  - to  design  telephone  switching 
equipment  to  meet  customer  requirements. 

- Requirements  examples  - traffic,  features 

- Output  - part  numbers,  quantities,  location 
assignments. 


Two  Stages  of  Configuration 

• Sales  - Creates  a design  down  to  the  level  of 
specificity  which  allows  a product  to  be 
priced,  contracted,  and  ordered. 

• Factory  - Uses  the  output  of  the  Sales 
Configurator  and  further  reduces  the 
solution  to  parts  that  can  be 
manufactured/assembled 


Configurator  Technology 

• Rules  - If  Then  Else,  Ratios,  Exclusions, 
etc. 

• Constraints  - Balances  resources  required 
and  resources  offered  by  components. 


Interoperability  - Input 

• Input  to  Configurators  from  Other  Systems 

- Sales  Configurator 

• Product/Part 

• Customer  Inventory 

- Factory  Configurator 

• Product/Part 

• Sales  Configurator  Output 


Interoperability  - Output 

• Sales  Configurator 

- Order  then  Factory  Configurator 

- Services 

- Sales  Management 

- Financial  - Revenue 

• Factory  Configurator 

- Shop  floor 

- Financial  - Cost  accounting 


Configurator 


Coordination  Problems 

• Sales  Configurator  outputs  product  codes 
not  recognized  by  order. 

• Sales  Configurator  outputs  product  codes 
not  recognized  by  Factory  Configurator. 

• Factory  Configurator  outputs  product  codes 
not  recognized  on  shop  floor. 

• Financial  can’t  match  Sales-Re venue  view 
of  product  with  Factory-Cost  view 


Interoperability  Issues 

• Knowledge  Based  systems  use  logic  (rules, 
constraints)  to  select  or  produce  data. 

• Data  needs  to  be  coordinated  across  systems 
that  share  it. 

• With  Knowledge  Based  systems  sharing 
from  a common  data  server  is  not  a 
solution. 

• Rules  and  data  need  to  be  managed  together 


Appendix  H - Presentation  Slides 

OKBC:  A Programming  Foundation  for  Knowledge-based  Interoperability 


Vinay  Chaudhri 
SRI  International 
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OKBC:  A Programmatic  Foundation 
for  Knowledge  Base  Interoperability 


Vinay  K.  Chaudhri 
Adam  Farquhar 
Richard  Fikes 
Peter  D.  Karp 
James  P.  Rice 


Artificial  Intelligence  Center  Knowledge  Systems  Laboratory 

SRI  International  Stanford  University 


Motivation 

ru  DARPA’s  High  Performance  Knowledge  Bases  Program  has  three 
knowledge  servers  and  about  20  technology  developers. 

• Loom  (Information  Sciences  Institute) 

• Ontolingua  (Knowledge  Systems  Laboratory,  Stanford) 

• CYC  (Cycorp) 

■ Some  technology  developers  are  required  to  work  with  multiple 
knowledge  servers. 


■ Some  technology  developers  will  be  required  to  change  affiliation  at 
the  end  of  first  year. 
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Approach 

a Three  knowledge  servers  will  support  OKBC  as  their  API 

• Supporting  OKBC  for  a system  means  defining  mappings  from 
OKBC  to  the  native  API  of  that  system 

■ Technology  developers  will  write  their  applications  using  OKBC 

• KB  browsers  and  editors 

• Theorem  provers 

• Knowledge  acquisition  tools 


g= Outline 

I ■ Design  Approach 
I ■ Overview  of  OKBC 
| ■ Some  Design  Difficulties 

■ OKBC  Compliance 

■ Implementation 

■ Future  Plans 
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Design  Approach 

Analyze  a few  knowledge  representation  systems  (KRSs),  and 
identify  a common  denominator 

• classes,  individuals, 

• add,  remove,  replace 

Represent  the  differences  using  behaviors 

• Some  KRSs  support  frame  names  and  others  do  not 

OKBC  = Knowledge  Model  + Operations  + Behaviors 


OKBC  Knowledge  Model 

Frames.  Represent  entities  in  the  world  (concrete  or  abstract).  Are 
organized  into  a taxonomy  of  classes  and  individuals 

• Person,  Organization 

Slots.  Represent  binary  relationships 

• Age,  Name 

Facets.  Represent  properties  of  slots 

• Value  Type  of  Age  is  Integer 

Subclass,  Instance-of,  Slot-of  and  Facet-of  relationships 
Knowledge  Base.  Is  a collection  of  frames 
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OKBC  Knowledge  Model 


Inheritance 

• Based  on  own  and  template  slots 

• Template  slots  inherit  to  subclasses  and  instances 

• For  example,  for  the  class  employee,  average  salary  is  an  own 
slot  and  address  is  a template  slot 


OKBC  Operations 

OKBC  supports  the  following  three  kinds  of  operations  on  each 
object  type  (frame,  class,  individual,  instance,  KBs,  slot,  facet) 

• retrieval  operations:  extract  information  about  objects  and  their 
slot  values 

aet-slot-values . aet-class-subclasses 

• manipulator  operations:  create,  destroy  or  modify  frames 

create-frame . put-slot-values,  put-instance-types 

• enumerator  operations:  batch  retrieval 

enumerate-slot-values 
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OKBC  Operations 

Tell/ask  interface 

• OKBC  defines  a restricted  assertion  language 

Classes,  slots  and  facets  are  relation  symbols 
subclass-of,  instance-of,  slot-of,  facet-of 
class,  individual 

• But,  tell  can  accept  any  sentences  that  are  tellable 

• Provides  unlimited  extensibility 


OKBC  Behaviors 


Behaviors  allow  KRSs  to  advertise  how  they  are  different 

• For  example,  support  for  frame  names 

• Applications  can  query  the  value  of  the  behavior  and  take 
appropriate  actions 

Behaviors  can  also  be  used  to  control  the  KRS 

• For  example,  constraint  checking 

• Applications  can  indicate  the  necessary  functionality  to  the  KRS 
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Example  use  with  LOOM 


(defconcept  Healthy-Parent  :is  (:and  Parent  (:at-ieast  3 child) 

(:at-most  2 son) 
(:exactly  1 pet))) 


(create-class  Healthy-Parent  Parent) 

(create-slot  child  Healthy-Parent) 

(create-slot  son  Healthy-Parent) 

(create-slot  pet  Healthy-Parent) 

(put-facet-value  Healthy-Parent  child  :minimum-cardinality  3) 
(put-facet-value  Healthy-Parent  son  :maximum-cardinality  2) 
(put-facet-value  Healthy-Parent  pet  :cardinality  1) 


Loom  contexts  are  represented  using  OKBC  KBs. 


Al  Center 


OKBC  Design  Issues 


Assumptions  about  entities  that  are  represented  as  frames 

• Semantics  of  frame  operations 
Inference  mechanisms 

• Control  of  inference 
Data  types 

• Symbols,  packages 
Deletion 

• Is  not  always  thorough 
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OKBC  Design  Issues 
All  Entities  are  not  Frames 

Should  get-kb-classes  return  classes  that  are  not  frames? 
e.g.,  (set-of  1 2 3) 

• Unreasonable  to  require  that  all  classes  be  frames 

• Classes  that  are  not  frames  are  inherently  different  from  the 
ones  that  are  frames 

• It  should  be  possible  to  pass  the  results  of  one  OKBC  operation 
to  another 


Decision: 


get-kb-classes  returns  only  those  classes  that  are  frames 


OKBC  Design  Issues 
All  Entity  Types  are  not  Frames 

Not  all  KRSs  represent  slots  as  frames 

If  we  execute  get-kb-frames  on  such  KRSs,  we  will  get  different 
results 

Solution: 

Introduce  a behavior  called  :are-frames  with  possible  values  of 
:class,  individual,  :slot,  and  :facet 

Desired  Behavior 


u For  two  KRSs  with  the  same  value  of  :are-frames  behavior,  get-kb- 
frames  is  guaranteed  to  return  the  same  result 


Achievable  Behavior 


■ Applications  are  made  aware  of  obvious  differences 
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ai  center  OKBC  Implementation 

ra  OKBC  implementation  for  Lisp  and  Java 

■ The  server  side  implementation  involves  implementing  about  50 
methods  that  define  mappings  from  the  API  of  a KRS  to  OKBC 
■ Mandatory  vs.  optional  methods 

■ OKBC  back  ends  are  available  for  LOOM,  Ontolingua,  Theo  and 
Sipe.  A read-only  back-end  is  available  for  Classic 
■ A network  version  of  OKBC  is  available  that  allows  remote 
execution  of  OKBC  operations. 


■ Network  version  supports  a procedure  language 


OKBC  Compliance 

A compliant  implementation  must  accept  all  legal  input  values  and 
return  documented  results 

While  using  OKBC,  two  types  of  problems  are  faced 

• Some  KRSs  support  knowledge  models  richer  than  the  one 
supported  by  OKBC 

• Some  KRSs  support  models  less  expressive  than  that  of  OKBC 
Four  compliance  classes  are  defined 

• Read  only 

• Monotonic 

• Facets  supported 

• User  defined  facets  supported 


Page  8 


Current  Work 


OKBC/CORBA  implementation 
Expand  knowledge  model 

• Assertions 

• Justification/Explanation 

• Contexts 

• Probabilities 


References 

://www.ai.sri.com/~okbc 
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Knowledge  Source  Awareness  Models  for  Interoperable  Knowledge- based  Systems 

Ramana  Reddy 
West  Virginia  University 


Slide  Presentations,  Knowledge-based  Systems  Interoperability  Workshop,  95 


Ramana  Reddy 
Concurrent  Engg.  Research 
Center 


Information  Sharing  Project CERC 

Premises 

♦ KBS’s  depend  on  knowledge  sources 

♦ Knowledge  exists  in  differing  formats 

♦ Knowledge  is  distributed 


Information  Sharing  Project CERC 

The  Challenge 


♦ Can  a KBS  discover  the  source  of 
knowledge,  decipher  it,  and  use  it  for  its 
operation? 


Information  Sharing  Project CERC 

A Trivial  Example 

♦ A knowledge  based  “Office  Assistant” 
needs  an  Address  Book 


♦ Can  the  MS -Outlook  find  and  use  the 
Netscape  Address  Book? 


Information  Sharing  Project 


CERC 


Imperatives  for  Inter-Operable 
KBS’s 

♦ Reasoning  models  for  KS  discovery 

♦ A taxonomy  for  domain-specific  knowledge 
sources 

♦ Transformers  (n+m  problem) 

♦ Learning 

♦ Pliant  systems 


Information  Sharing  Project 


CERC 


Goals  of  Information  Sharing 


Provide  easy,  uniform,  secure  and  transparent  ways  to  share ; 
heterogeneous  information  in  support  of  organizational  processes  and  policies.  J 


Information  Sharing  Project CERC 

Medical  Domain  Problem 


Information  Sharing  Project CERC 

Barriers  to  Enterprise  Information  Sharing 

•Proprietary  Information  and  Security  protocols 

•Lack  of  Interoperability  among  the  heterogenous 
hardware  and  software  platforms  used  to  store 
information 

•Lack  of  an  Information  Directory 
•Data  format  incompatibility 
•Proliferation  of  media 


Information  Sharing  Project 


CERC 


CERC  ISS  Approach 


An  enterprise  model  provides  an  integrated  v 
information  in  remote  data  repositories. 


Information  Sharing  Project 


CERC 


ISS  (Version  3.0)  Features 

•Adoption  of  "HTTP"  protocol  for  client-end  interoperability. 

•Adoption  of  "CORBA"  specifications  for  server-end  interoperability 
using  Orbix™. 

•Gateways  to  Commercial  relational  database  (Oracle™). 

•Adoption  of  "Kerberos"  for  authentication. 

•Model-based  Wide-area  access  and  update  capabilities 
to  structured  and  unstructured  information. 

•Federated  access  control  mechanisms  (Information 
provider  decides  who  can  access  information). 

•Adoption  of  Hyper- text  document  metaphor  (Mosaic) 
to  support  ease-of-use. 


Information  Sharing  Project 


ISS  Version  3.0  Modules 


CORBA  interface  (ORBDC™) 
HTTP  interface 


CERC 


Information  Sharing  Project CERC 

ARTEMIS  Project 


Wavne  Health  Service  (VHS) 


